Shallow Thoughts : tags : window managers
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Thu, 28 Sep 2023
My search for a good desktop Mastodon client has led me down a path
that involved learning some fun ways to interact with existing
browser windows on Linux with X programs like
xdotool and wmctrl.
Like many people, I've switched from The App Formerly Known As Twitter
to Mastodon (where I'm
@akkana@fosstodon.org).
But the next question was which Mastodon app to use.
Read more ...
Tags: linux, firefox, browsers, python, X11, window managers, openbox
[
11:48 Sep 28, 2023
More linux |
permalink to this entry |
]
Fri, 25 Aug 2023
When I wrote about
Getting Linux System Notifications under Openbox,
I ended up tossing out the whole notification system and using zenity
to pop up a dialog directly. Specifically, a command like
XAUTHORITY=~/.Xauthority DISPLAY=:0 zenity --title "Hello" --info --text="Hello world"
But customizing zenity to make it more attention-getting turned out to
be more difficult than expected ...
Read more ...
Tags: linux, openbox, window managers
[
13:55 Aug 25, 2023
More linux |
permalink to this entry |
]
Mon, 21 Aug 2023
I've been a fan of Linux's lightweight window managers, particularly
Openbox, for many years.
But admittedly, there are some things they don't generally handle.
One of those is system notifications.
Mostly, I've been happy to go without notifications. Firefox is
forever asking me whether I want to turn them on for particular websites
(which wouldn't work, but Firefox doesn't know that), usually websites
I'm visiting for the first time and probably don't ever want to visit again,
let alone let them spam me with ads as notifications outside my browser.
But every now and then it would be handy.
Read more ...
Tags: linux, openbox, window managers
[
14:03 Aug 21, 2023
More linux |
permalink to this entry |
]
Sun, 24 Nov 2019
I have a new laptop, a birthday present to myself last month.
For once, rather than buying a cut-rate netbook, I decided to
treat myself to a fancy Lenovo Carbon X1 with an up-to-date processor
and lots of RAM.
Since I have way more resources than I'm used to, I decided I'd try
installing a full Ubuntu and not trying to pare it down to a super
lightweight system. I'm still running the lightweight, fast, highly
configurable Openbox window manager instead of a full Gnome desktop:
Openbox does just what I tell it and no more, and doesn't surprise me
with random redesigns. But I did let Ubuntu install some system
utilities I've always avoided in the past, like NetworkManager and
PulseAudio. I decided I'd give them a chance, see if they've gotten
better since I last checked.
They have, though they're still a bit of a hassle to deal with.
NetworkManager can be controlled through nmcli, which is poorly
documented but works okay if you google long enough to find the
proper incancations. PulseAudio gave me a bit more trouble.
The standard GUI for controlling PulseAudio is pavucontrol
.
It showed two audio devices: "USB PnP Audio Device Analog Stereo" and
"Built-in Audio Analog Stereo". Turns out the USB PnP option is a
sound card built into the USB hub, a Totu tt-hb003a 11-in-1 USB-C hub
that lets me connect to a charger, external monitor, SD and micro-SD
slots, and extra USB ports without juggling a lot of extra cables.
Pulse assumes -- probably reasonably, though it's wrong in this case
-- that if I have a USB audio device connected, I probably want to use
it in preference to the laptop's built-in audio. That would make sense
if I had external speakers plugged in, but I left all my computer
speakers behind when I moved. I should probably order some speakers.
But meanwhile, I needed to persuade PulseAudio to ignore the hub and
use the laptop's built-in sound system.
Mute/Unmute via the Keyboard
The Lenovo, like most laptops, has a dedicated key for muting, Fn-F1.
It even has a little light on it to show whether it's muted. In
Openbox, pressing Fn-F1 actually muted the sound, and even turned on
the light. This is probably because I'd previously set
key="XF86AudioMute" to run amixer set Master toggle
in .config/openbox/rc.xml, which worked on my Pulse-free
pared-down Debian netbook. The problem is that pressing iFn-F1 again
didn't bring the sound back. Instead, it was unmuting the USB hub's audio.
Clicking "Set as fallback" on the built-in audio in pavucontrol made
no difference.
It turns out that it is virtually impossible to persuade PulseAudio to
use "Built-in Audio" when a "USB PnP Audio Device" is available. I
finally found the secret: in pavucontrol's Configuration tab,
set Profile for the PnP USB device to Off. Now only the
built-in device shows up in the other tabs.
But that amixer command still wasn't unmuting properly, so the next
step was to find a command that would actually unmute. Someone on
#linux suggested pactl set-sink-mute @DEFAULT_SINK@ toggle
and that worked great from the command line. But when I tried to bind it
in Openbox to the XF86AudioMute key, it did nothing. I still
don't understand why not; I wasted a lot of time comparing my
shell environment to openbox's environment and never found the
difference.
Back to web searching, I found an
askbuntu thread suggesting
some Openbox stanzas. In particular, it apparently works better to use
alsamixer rather than pactl. This finally worked for toggling mute:
<keybind key="XF86AudioMute">
<action name="Execute">
<command>amixer -q -D pulse sset Master toggle</command>
</action>
</keybind>
Volume Controls via Function Keys
Partial success! Unfortunately, the volume control commands in that
same askbuntu post, amixer -q -D pulse sset Master 3%+ unmute
,
did nothing. I had already noticed that in pavucontrol, the volume
controls didn't work either. In fact, if I started some music playing
and then called up alsamixer, channels like Master and Speaker didn't
do anything; the only channel that affected volume was ALSA PCM. After some
fiddling, I discovered that I had to change Master to PCM and
remove the -D pulse:
<keybind key="XF86AudioRaiseVolume">
<action name="Execute">
<command>amixer sset PCM 4%+ unmute</command>
</action>
</keybind>
<keybind key="XF86AudioLowerVolume">
<action name="Execute">
<command>amixer sset PCM 4%- unmute</command>
</action>
</keybind>
I'm sure I'll eventually need to fiddle some more. For one thing,
if I ever want to use audio during a talk (as I did briefly at my
Stonehenge talk earlier this year) I'll need to figure out how to
enable a temporary HDMI sound sink quickly without needing to fiddle
with pavucontrol. But for now, I'm happy to have
the basic laptop volume and mute keys working.
Tags: linux, audio, cmdline, window managers
[
15:43 Nov 24, 2019
More linux |
permalink to this entry |
]
Mon, 20 Oct 2008
Someone on #openbox this morning wanted help in bringing up a window
without decorations -- no titlebar or window borders.
Afterward, Mikael commented that the app should really be coded
not to have borders in the first place.
Me: You can do that?
Turns out it's not a standard ICCCM request, but one that mwm
introduced, MWM_HINTS_DECORATIONS.
Mikael pointed me to the urxvt source as an example of an app that uses it.
My own need was more modest: my little
moonroot
Xlib program that draws the moon at approximately its current phase.
Since the code is a lot simpler than urxvt, perhaps the new version,
moonroot 0.4, will be useful as an example for someone (it's also
an example of how to use the X Shape extension for making
non-rectangular windows).
Tags: programming, xlib, astronomy, window managers
[
12:06 Oct 20, 2008
More programming |
permalink to this entry |
]
Sun, 17 Jun 2007
It was a bit over two years ago that I
switched from
icewm to fvwm as my window manager. Fvwm proved to be very fast,
very configurable, and "good enough" most of the time. But lately,
I've found myself irritated with it, particularly with its tendency to
position windows off screen (which got a lot worse in 2.5.18).
It looked like it was time to try another window manager, so when
I learned that the
Openbox
project is headed by a fellow
LinuxChixor, I had to try it.
Openbox impressed me right away. I'd tried it once before, a couple of years
ago, when I found it a little inconsistent and immature. It's grown up a
lot since then! It's still very fast and lightweight, but it has good
focus handling, excellent window positioning, a good configuration
window (obconf), and a wide variety of themes which are pretty but
still don't take up too much of my limited screen space.
But more important, what it has is a very active and friendly
community. I hit a couple of snags, mostly having to do with focus
handling while switching desktops (the problem that drove me off
icewm to fvwm), so I hopped onto the IRC channel and found myself
chatting with the active developers, who told me that most of my
problems had already been fixed in 3.4, and there were .deb files
on the website for both of the distros I'm currently using.
Indeed, that cured the problem; and when I later hit a more esoteric
focus bug, the developers (particularly Dana Jansens) were all over it
and fixed it that same day. Wow!
Since then I've been putting it through its paces. I have yet to see
a window positioned badly in normal usage, and it handles several
other problems I'd been seeing with fvwm, like focus handling when
popping up dialogs (all those secondary GIMP Save-as dialogs that
don't get focused when they appear). It's just as flexible as fvwm
was when it comes to keyboard and mouse configuration, maybe even
more so (plus it has lots of useful default bindings I might not
have thought of, like mousewheel bindings to change desktops or
"shade" a window).
I was going to stay out of theme configuration, because there were
several pretty good installed themes already. But then in response to
a half-joking question on my part of whether a particular theme came
in blue, someone on the IRC channel made me a custom theme file -- and
I couldn't resist tweaking it from there, and discovered that tweaking
openbox themes is just as easy as fiddling with its other defaults.
I don't use transparency (I find it distracting), but my husband is
addicted to transparent windows, so when I noticed on the web site
that openbox handles transparency I pointed him there. (He's been
using an old Afterstep, from back when it was still small and light,
but it's been a constant battle getting it to build under newer gccs.)
He reports that openbox handles transparency as well as afterstep did,
so he's switched too.
I haven't looked at the openbox code yet, but based on how fast the
developers add features and fix bugs, I bet it's clean, and I
hope I can contribute at some point.
Anyway, great focus handling, great window positioning, fast,
lightweight, super configurable, and best of all a friendly and
helpful developer and user community. What more could you ask for in a
window manager?
I'm an openbox convert. Thanks, Dana, Mikachu and all the rest.
Tags: linux, X11, window managers
[
14:13 Jun 17, 2007
More linux |
permalink to this entry |
]
Mon, 13 Dec 2004
I've been alternating between icewm and openbox for my window manager,
but I'm not entirely happy with either one. They're both fast to
start up, which is important to me, but I've had frustrations
mostly relating to window focus -- which window becomes focused when
switching from one desktop to another (icewm's biggest problem) or
when a window resizes (openbox), and also with initial window positioning
and desktop location (e.g. making one window span all desktops without
having to select a menu item every time I run that app).
Someone was opining on IRC about fvwm and its wonderful configurability,
and that made me realize that I haven't really given fvwm a chance in
a long, long time. Time to see if I was missing anything!
The defaults are terrible. No wonder I didn't stick with fvwm after
newer windowmanagers came out! It's definitely not an install-and-go
sort of program. Nor is the documentation (a long and seemingly
thorough man page) clear on how to get started configuring it.
Eventually I figured out that it looks for ~/.fvwm/config, and
that some sample configs were in /usr/share/doc/fvwm/sample.fvwmrc
(which is a directory), and I went from there. After several hours
of hacking, googling, and asking questions on #fvwm, I had a setup
which rivals any window manager I've found: it's fast, lets me configure
the look of my windows, lets me bind just about anything to keys,
and seems pretty well behaved focus behavior. More important,
it also allows me to specify special behavior for certain windows,
for example, making xchat always occupy all desktops:
Style "xchat" Sticky
which is something I've wanted but haven't been able to do in
any other lightweight window manager. That alone may keep me
in fvwm for the forseeable future.
Tips for things that were non-obvious:
Rotating through three desktops
In other window managers, I define three desktops, and use ctrl-alt-right
and left to cycle through them, rotating, so going right from 3 goes to
desktop 1. fvwm has both "pages" (a virtual desktop can be bigger than
the screen, and mousing off the right side scrolls right one page) and
desktops. I didn't want pages, only desktops, so
DeskTopSize 1x1
turns off the pages, and it was clear from the man page that
PointerKey Left A CM GotoDesk -1
would go left one desk (the only unclear part about that is that A
in the modifier list means "Any", not "Alt", and "M" (presumably for
"meta" means alt, not the windows-key which some programs use for meta).
"PointerKey" is needed instead of "Key" because otherwise fvwm gets
confused when using the "sloppy focus" model (the man page warns
about that).
The question was, how to limit fvwm to three
desktops, and wrap around, rather than just going left to new desktops
forever? The answer (courtesy of someone on IRC) turned out to be:
PointerKey Left A CM GotoDesk -1 0 2
PointerKey Right A CM GotoDesk 1 0 2
PointerKey Left A CMS MoveToDesk -1 0 2
PointerKey Right A CMS MoveToDesk 1 0 2
The only problem at this point is that MoveToDesk doesn't then change
to the new desktop, the way other window managers do, but I'm confident
that will be easily solved.
Titlebar buttons
I had the hardest time getting buttons (e.g. maximize, close)
to appear on the titlebars of my windows. You'd think this would
happen by default, but it doesn't. It turned out that titlebar buttons
aren't drawn unless there's a key or mouse action bound to that button,
which they aren't by default. So to get buttons for window menu,
maximize, and close, I had to do:
Mouse 1 6 A Close
Mouse 1 8 A Maximize
Mouse 1 1 A Menu Window-Ops Nop
But then showing buttons 6 and 8 (the even buttons are numbered
from the top right) automatically turns on 2 and 4 (I chose 6 and
8 because their default shapes were vaguely mnemonic), so they have
to be turned off again:
Style * NoButton 2
Style * NoButton 4
Smaller titlebar and window frame
I also wanted to reduce the titlebar height and the width of the window
frame: I don't like wasting all that screen real estate. That, too,
took a long time to figure out. It turns out I had to define my own
theme in order to do that, then add a couple of undocumented items
to my theme. There's lots of documentation around on how to make
buttons and background images and menus and key bindings in themes,
but none of the documentation mentions simple stuff like titlebar height.
DestroyDecor MyDecor
AddToDecor MyDecor
+ TitleStyle Height 16
+ Style "*" BorderWidth 5, HandleWidth 5
+ ButtonStyle All -- UseTitleStyle
Style "*" UseDecor MyDecor
New windows should grab focus
Most window managers do this by default, but fvwm doesn't, and requires:
Style * FPGrabFocus
Full config file
For any other settings, see my
fvwm config file.
Tags: linux, X11, window managers
[
18:14 Dec 13, 2004
More linux |
permalink to this entry |
]
Mon, 09 Aug 2004
Searching, as always, for the perfect window manager ...
Helix likes ion3, because it handles key accelerators very well,
so I thought I'd try it.
I don't really like the "tiled or fullscreen" model it uses by
default, but found the answer in the FAQ (after a rude RTFM comment
which made no sense, since I already had RTFM and it doesn't give
information on anything but runtime arguments): press F9 and get
it to prompt for the type of the new workspace (the correct answer
is the one with "Float" in the name).
All of the available themes use the "small grab handle around the
title, but the rest of the titlebar isn't there" look. I don't like
that (it's harder to find a place to grab to move windows around)
though I suppose I could get used to it. Not a big deal.
It does look like it has good key binding support, and ways to
specify different behavior for different apps, both of which would
be very nice. Focus behavior on resize seems to be the same as openbox
and icewm, though: if the window resizes out from under the cursor,
it loses focus. Also the root menus (right-click) are a pain: they
don't stay posted, and they're small, so it's hard to navigate them.
I'm sure ion3 has some coolnesses, but I decided that it didn't look
likely enough to solve my problems to be worth learning how to
configure it (and that unjustified RTFM left a bad taste in my
mouth about how easy that configuration was likely to be). So
I'm back on openbox for a little while, anyway.
Here's what I want out of a window manager:
- First, startup speed and basic operation comparable to icewm or openbox
(my two faves so far).
- Intelligent handling of keyboard focus even when in "focus follows mouse"
mode. That means:
- When switching workspaces, focus goes either to the window
under the mouse, or the window on that workspace which last
had the focus (either one would be fine). Openbox does this
pretty well; icewm's focus is pretty random.
- When resizing a window that has focus, it should keep the
focus even if it resizes out from under the mouse.
- Click in a window focuses (but doesn't necessarily raise) that window.
(Again, openbox does this well, icewm doesn't.)
- A new window or dialog gets focused.
- A way of setting up rules for different windows:
e.g. I want xchat to be on all workspaces, or I want moonroot to
come up with no window borders. I shouldn't have to do a
right-click-and-menu-selection operation every single time I
run xchat.
- Easy configuration to start apps with from a menu on the root
or via key bindings (or, ideally, both). No dependance on
having a panel (which was why I quit using xfce4).
Both icewm and openbox handle this well.
- A way of navigating among windows using only the keyboard.
Both openbox and icewm allow for easy movement between
workspaces and moving windows between workspaces, but in both
of them, alt-tab toggles between the current app and the last
app on that workspace, and there seems to be no way to get to
anything besides those two.
Tags: linux, X11, window managers
[
18:36 Aug 09, 2004
More linux |
permalink to this entry |
]